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Abstract 


This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a 
mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS 
protocol values that may be advertised to ensure peers correctly handle unknown values. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not all documents approved by 
the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8701. 


Copyright Notice 


Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility 


January 2020 


The TLS protocol [RFC8446] includes several points of extensibility, including the list of cipher 


suites and several lists of extensions. The values transmitted in these lists identify 


implementation capabilities. TLS follows a model where one side, usually the client, advertises 
capabilities, and the peer, usually the server, selects them. The responding side must ignore 
unknown values so that new capabilities may be introduced to the ecosystem while maintaining 
interoperability. 


However, bugs may cause an implementation to reject unknown values. It will interoperate with 
existing peers, so the mistake may spread through the ecosystem unnoticed. Later, when new 
values are defined, updated peers will discover that the metaphorical joint in the protocol has 


rusted shut and the new values cannot be deployed without interoperability failures. 
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To avoid this problem, this document reserves some currently unused values for TLS 
implementations to advertise at random. Correctly implemented peers will ignore these values 
and interoperate. Peers that do not tolerate unknown values will fail to interoperate, revealing 
the mistake before it is widespread. 


In keeping with the rusted joint metaphor, this technique is called "GREASE" (Generate Random 
Extensions And Sustain Extensibility). 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


2. GREASE Values 


This document reserves a number of TLS protocol values, referred to as GREASE values. These 
values were allocated sparsely to discourage server implementations from conditioning on them. 
For convenience, they were also chosen so all types share a number scheme with a consistent 
pattern while avoiding collisions with any existing applicable registries in TLS. 


The following values are reserved as GREASE values for cipher suites and Application-Layer 
Protocol Negotiation (ALPN) [RFC7301] identifiers: 

{0x0A,0x0A} 

{0x1A,0x1A} 

{0x2A,0x2A} 

{0x3A,0x3A} 

{0x4A,0x4A} 

{0x5A,0x5A} 

{0x6A,0x6A} 

{0x7A,0x7A} 

{0x8A,0x8A} 

{0x9A,0x9A} 

{OxAA,0xAA} 

{0xBA,OxBA} 

{0xCA,0xCA} 

{0xDA,0xDA} 

{OxEA,OXEA} 

{OxFA,OxFA} 


Benjamin Informational Page 3 


RFC 8701 Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility January 2020 


The following values are reserved as GREASE values for extensions, named groups, signature 
algorithms, and versions: 

Ox0A0A 

0x1A1A 

Ox2A2A 

0x3A3A 

0Ox4A4A 

Ox5A5A 

Ox6A6A 

Ox7A7A 

Ox8A8A 

Ox9A9A 

OxAAAA 

OxBABA 

OxCACA 

OxDADA 

OxEAEA 

OxFAFA 


The values allocated above are thus no longer available for use as TLS or DTLS [RFC6347] version 
numbers. 


The following values are reserved as GREASE values for PskKeyExchangeModes: 


0x0B 
Ox2A 
0x49 
0x68 
0x87 
OxA6 
OxC5 
OxE4 


3. Client-Initiated Extension Points 


Most extension points in TLS are offered by the client and selected by the server. This section 
details client and server behavior around GREASE values for these. 
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3.1. Client Behavior 


When sending a ClientHello, a client MAY behave as follows: 


° A client MAY select one or more GREASE cipher suite values and advertise them in the 
"cipher_suites" field. 


A client MAY select one or more GREASE extension values and advertise them as extensions 
with varying length and contents. 


A client MAY select one or more GREASE named group values and advertise them in the 
"supported_groups" extension, if sent. It MAY also send KeyShareEntry values for a subset of 
those selected in the "key_share" extension. For each of these, the "key_exchange" field MAY 
be any value. 


A client MAY select one or more GREASE signature algorithm values and advertise them in 
the "signature_algorithms" or "signature_algorithms_cert" extensions, if sent. 


A client MAY select one or more GREASE version values and advertise them in the 
"supported_versions" extension, if sent. 


A client MAY select one or more GREASE PskKeyExchangeMode values and advertise them in 
the "psk_key_exchange_modes" extension, if sent. 

A client MAY select one or more GREASE ALPN identifiers and advertise them in the 
“application_layer_protocol_negotiation" extension, if sent. 


Clients MUST reject GREASE values when negotiated by the server. In particular, the client MUST 
fail the connection if a GREASE value appears in any of the following: 


e The "version" value in a ServerHello or HelloRetryRequest 

e The "cipher_suite" value in a ServerHello 

e Any ServerHello extension 

e Any HelloRetryRequest, EncryptedExtensions, or Certificate extension in TLS 1.3 

e The "namedcurve" value in a ServerKeyExchange for an Ephemeral Elliptic Curve Diffie- 
Hellman (ECDHE) cipher in TLS 1.2 [RFC5246] or earlier 

e The signature algorithm in a ServerKeyExchange signature in TLS 1.2 or earlier 

e The signature algorithm in a server CertificateVerify signature in TLS 1.3 


Note that this can be implemented without special processing on the client. The client is already 
required to reject unknown server-selected values, so it may leave GREASE values as unknown 
and reuse the existing logic. 


3.2. Server Behavior 


When processing a ClientHello, servers MUST NOT treat GREASE values differently from any 
unknown value. Servers MUST NOT negotiate any GREASE value when offered in a ClientHello. 
Servers MUST correctly ignore unknown values in a ClientHello and attempt to negotiate with 
one of the remaining parameters. (There may not be any known parameters remaining, in which 
case parameter negotiation will fail.) 
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Note that these requirements are restatements or corollaries of existing server requirements in 
TLS. 


4. Server-Initiated Extension Points 


Some extension points are offered by the server and selected by the client. This section details 
client and server behavior around GREASE values for these. 


4.1. Server Behavior 


When sending a CertificateRequest in TLS 1.3, a server MAY behave as follows: 


e A server MAY select one or more GREASE extension values and advertise them as extensions 
with varying length and contents. 

e A server MAY select one or more GREASE signature algorithm values and advertise them in 
the "signature_algorithms" or "signature_algorithms_cert" extensions, if present. 


When sending a NewSessionTicket message in TLS 1.3, a server MAY select one or more GREASE 
extension values and advertise them as extensions with varying length and contents. 


Servers MUST reject GREASE values when negotiated by the client. In particular, the server MUST 
fail the connection if a GREASE value appears in any of the following: 


e Any Certificate extension in TLS 1.3 
e The signature algorithm in a client CertificateVerify signature 


Note that this can be implemented without special processing on the server. The server is already 
required to reject unknown client-selected values, so it may leave GREASE values as unknown 
and reuse the existing logic. 


4.2. Client Behavior 


When processing a CertificateRequest or NewSessionTicket, clients MUST NOT treat GREASE 
values differently from any unknown value. Clients MUST NOT negotiate any GREASE value when 
offered by the server. Clients MUST correctly ignore unknown values offered by the server and 
attempt to negotiate with one of the remaining parameters. (There may not be any known 
parameters remaining, in which case parameter negotiation will fail.) 


Note that these requirements are restatements or corollaries of existing client requirements in 


TLS. 


5. Sending GREASE Values 


Implementations advertising GREASE values SHOULD select them at random. This is intended to 
encourage implementations to ignore all unknown values rather than any individual value. 
Implementations MUST honor protocol specifications when sending GREASE values. For instance, 
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Section 4.2 of [RFC8446] forbids duplicate extension types within a single extension block. 
Implementations sending multiple GREASE extensions in a single block must therefore ensure 
the same value is not selected twice. 


Implementations SHOULD balance diversity in GREASE advertisements with determinism. For 
example, a client that randomly varies GREASE value positions for each connection may only fail 
against a broken server with some probability. This risks the failure being masked by automatic 
retries. A client that positions GREASE values deterministically over a period of time (such as a 
single software release) stresses fewer cases but is more likely to detect bugs from those cases. 


6. IANA Considerations 


This document updates the "TLS Cipher Suites" registry, available at <https://www.iana.org/ 
assignments/tls-parameters>: 
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Value 
{0x0A,0x0A} 
{0x1A,0x1A} 
{0x2A,0x2A} 
{0x3A,0x3A} 
{0x4A,0x4A} 
{0x5A,0x5A} 
{0x6A,0x6A} 
{0x7A,0x7A} 
{0x8A,0x8A} 
{0x9A,0x9A} 
{OxAA,OxAA} 
{OxBA,OxBA} 
{OxCA,0xCA} 
{0xDA,OxDA} 
{OxEA,OxEA} 


{OxFA,OxFA} 


Description 
Reserved Y 
Reserved Y 
Reserved Y 
Reserved Y 
Reserved Y 
Reserved Y 
Reserved Y: 
Reserved Y 
Reserved Y 
Reserved Y 
Reserved Y 
Reserved Y 
Reserved Y 
Reserved Y 
Reserved Y 
Reserved Y 


Table 1: Additions to the TLS Cipher Suites Registry 


N 


z E20 2 fz20 2 Fz 2 Ezi z2 F2 z2 Fz z Ezi z 


DTLS-OK Recommended Reference 


[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 


[RFC8701] 
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This document updates the "TLS Supported Groups" registry, available at <https://www.iana.org/ 
assignments/tls-parameters>: 
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2570 Reserved 
6682 Reserved 

10794 Reserved 

14906 Reserved 

19018 Reserved 


DTLS-OK Recommended Reference 


Y 


Y 
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[RFC8701] 
[RFC8701] 
[RFC8701] 
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Value 


23130 


27242 


31354 


35466 


39578 


43690 


47802 


51914 


56026 


60138 


64250 


Table 2: Additions to the TLS Supported Groups Registry 


Description 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Y 


Y 


Y 


N 


z0 Z Ezi z2 EZI z2 Ezi z Ez 


N 


DTLS-OK Recommended Reference 


[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 


[RFC8701] 


This document updates the "TLS ExtensionType Values" registry, available at <https:// 


www.iana.org/assignments/tls-extensiontype-values>: 
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Value 


2570 


6682 


10794 


14906 


19018 


23130 


27242 


31354 


35466 


39578 


Extension Name 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


TLS 1.3 
CHICRINSE 
CH, CR, NST 
CH, CR, NST 
CH, CR, NST 
CH, CR, NST 
CH, CR, NST 
CH, CR, NST 
CH, CR, NST 
CH, CR, NST 


CH, CR, NST 
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Recommended Reference 


N 


z E20 2 Ezi z2 Ezi z Ezi 24 


[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 


[RFC8701] 
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Value 


43690 


47802 


51914 


56026 


60138 


64250 


Extension Name 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


TLS 1.3 
CH, CR, NST 
CH, CR, NST 
CH, CR, NST 
CH, CR, NST 
CH, CR, NST 


CH, CR, NST 


N 


2/2/4/24 


N 


Table 3: Additions to the TLS ExtensionType Values Registry 


Recommended Reference 


[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 


[RFC8701] 


registry, available at <https://www.iana.org/assignments/tls-extensiontype-values>: 
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Protocol 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Reserved 


Identification Sequence 


0x0A Ox0A 


0x1A 0x1A 


0x2A Ox2A 


0x3A 0x3A 


0x4A 0x4A 


0x5A Ox5A 


Ox6A 0x6A 


0x7A Ox7A 


0x8A 0x8A 


0x9A Ox9A 


OxAA 0xAA 


OxBA 0xBA 


OxCA OxCA 


0xDA 0xDA 


OxEA OxEA 
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[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
[RFC8701] 
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Protocol Identification Sequence Reference 


Reserved OxFA OxFA [RFC8701] 


Table 4: Additions to the TLS Application-Layer Protocol 
Negotiation (ALPN) Protocol IDs Registry 


7. Security Considerations 


GREASE values cannot be negotiated, so they do not directly impact the security of TLS 
connections. 


Historically, when interoperability problems arise in deploying new TLS features, 
implementations have used a fallback retry on error with the feature disabled. This allows an 
active attacker to silently disable the new feature. By preventing a class of such interoperability 
problems, GREASE reduces the need for this kind of fallback. Implementations SHOULD NOT 
retry with GREASE disabled on connection failure. While allowing an attacker to disable GREASE 
is unlikely to have immediate security consequences, such a fallback would prevent GREASE 
from defending against extensibility failures. 


If an implementation does not select GREASE values at random, it is possible it will allow for 
fingerprinting of the implementation or perhaps even of individual users. This can result ina 
negative impact to a user's privacy. 
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